Transmission Communication Protocol (TCP), now quite commonly used in computer network communications, is not a single protocol but actually a family of techniques that are used provide stable and reliable transfer of packet data across an Internet Protocol (IP) connection. The original design of TCP established a stream-based reliable protocol which would work over essentially any type of underlying physical network. The original TCP protocol used a “sliding window”, and specified that after packets are sent by a transmitter, acknowledgement packets (ACKs) must be sent from the receiver, before the transmitter is enabled to send new data.
The first widely available version of TCP (4.2 BSD, in 1983) worked reliably in Local Area Networks (LANs). As it was intended initially for implementation on LANs, it was sometimes unable to provide acceptable performance in large, shared (possibly congested) networks such as the Internet. Later implementations of TCP thus evolved to ensure maximum data throughput with minimum loss in widely distributed, shared networks. These later versions of TCP control not only the window size, but also the number of packets sent together in each “burst” or “segment”, a packet size, and the timing of packet acknowledgments by the receiver.
For example, the “Tahoe” implementation of TCP introduced significant improvements in congestion control (via a so-called “slow start” algorithm) and congestion avoidance (via multiplicative decrease). Under this algorithm, a TCP transmitter is allowed to transmit a number of bytes determined by the smallest value of the window advertised by the receiver and a congestion window. The congestion window (which is a variable called ‘cwnd’ in the TCP standard) is initially set to a value of one (1) packet (segment). The value of ‘cwnd’ is then doubled following successful receipt of each ACK. This results in a normally expected exponential size growth in the value of ‘cwnd’.
Tahoe also uses a variable to keep a threshold value of the send window (‘ssthresh’) which is initialized to the receiver's advertised window size. Following a transmission time out (e.g., when no ACK is received) the algorithm assigns half of the current window size to ‘ssthresh’ (a multiplicative decrease), ‘cwnd’ is set to a value of one again, and the slow start phase begins again.
The “Reno” version of TCP introduced a further optimization, called Fast Recovery, to improve performance following retransmission. When duplicate ACKs are received, a Reno TCP transmitter sets ‘ssthresh’ to one-half of ‘cwnd’ and retransmits the missing segment. ‘Cwnd’ is then increased by one segment on reception of each duplicate ACK.
A proposed modification to Reno, called “New Reno”, attempts to address two further problems with Reno. Specifically, a smaller value for ssthresh can cause premature termination of the slow start phase and subsequent slow increase in cwnd. A larger value may cause the sender to over-feed packets (i.e., transmit too long of a burst of data packets) causing congestion. New Reno attempts to optimize ssthresh by calculating the byte equivalent of the “bandwidth-delay product” of the network by measuring the arrival time of closely spaced ACKs at the sender.
More information on TCP protocols can be found in various Internet Engineering Task Force (IETF) Request for Comment (RFC) documents such as:
RFC 2001 “TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms”, January 1997; and
RFC 2582 “The New Reno Modification to TCP's Fast Recovery Algorithm”, April 1999.
These documents are available from the Internet Engineering Task Force (IETF) at their web site at http://www.ietf.org/.
In addition, a description of the threshold optimization schemes used by New Reno can be found in U.S. Pat. No. 6,643,259 issued to Borella, et al.